Will My Tests Tell Me If I Break This Code?

Automated tests play an important role in software evolution because they can rapidly detect faults introduced during changes. In practice, code-coverage metrics are often used as criteria to evaluate the effectiveness of test suites with focus on regression faults. However, code coverage only expresses which portion of a system has been executed by tests, but not how effective the tests actually are in detecting regression faults. Our goal was to evaluate the validity of code coverage as a measure for test effectiveness. To do so, we conducted an empirical study in which we applied an extreme mutation testing approach to analyze the tests of open-source projects written in Java. We assessed the ratio of pseudo-tested methods (those tested in a way such that faults would not be detected) to all covered methods and judged their impact on the software project. The results show that the ratio of pseudo-tested methods is acceptable for unit tests but not for system tests (that execute large portions of the whole system). Therefore, we conclude that the coverage metric is only a valid effectiveness indicator for unit tests.Comment: 7 pages, 3 figure

Too Trivial To Test? An Inverse View on Defect Prediction to Identify Methods with Low Fault Risk

Background. Test resources are usually limited and therefore it is often not possible to completely test an application before a release. To cope with the problem of scarce resources, development teams can apply defect prediction to identify fault-prone code regions. However, defect prediction tends to low precision in cross-project prediction scenarios. Aims. We take an inverse view on defect prediction and aim to identify methods that can be deferred when testing because they contain hardly any faults due to their code being "trivial". We expect that characteristics of such methods might be project-independent, so that our approach could improve cross-project predictions. Method. We compute code metrics and apply association rule mining to create rules for identifying methods with low fault risk. We conduct an empirical study to assess our approach with six Java open-source projects containing precise fault data at the method level. Results. Our results show that inverse defect prediction can identify approx. 32-44% of the methods of a project to have a low fault risk; on average, they are about six times less likely to contain a fault than other methods. In cross-project predictions with larger, more diversified training sets, identified methods are even eleven times less likely to contain a fault. Conclusions. Inverse defect prediction supports the efficient allocation of test resources by identifying methods that can be treated with less priority in testing activities and is well applicable in cross-project prediction scenarios.Comment: Submitted to PeerJ C

Cryogenic silicon surface ion trap

Trapped ions are pre-eminent candidates for building quantum information processors and quantum simulators. They have been used to demonstrate quantum gates and algorithms, quantum error correction, and basic quantum simulations. However, to realise the full potential of such systems and make scalable trapped-ion quantum computing a reality, there exist a number of practical problems which must be solved. These include tackling the observed high ion-heating rates and creating scalable trap structures which can be simply and reliably produced. Here, we report on cryogenically operated silicon ion traps which can be rapidly and easily fabricated using standard semiconductor technologies. Single $^{40}$Ca$^+$ ions have been trapped and used to characterize the trap operation. Long ion lifetimes were observed with the traps exhibiting heating rates as low as $\dot{\bar{n}}=$ 0.33 phonons/s at an ion-electrode distance of 230 $\mu$m. These results open many new avenues to arrays of micro-fabricated ion traps.Comment: 12 pages, 4 figures, 1 tabl

Is the Stack Distance Between Test Case and Method Correlated With Test Effectiveness?

Mutation testing is a means to assess the effectiveness of a test suite and its outcome is considered more meaningful than code coverage metrics. However, despite several optimizations, mutation testing requires a significant computational effort and has not been widely adopted in industry. Therefore, we study in this paper whether test effectiveness can be approximated using a more light-weight approach. We hypothesize that a test case is more likely to detect faults in methods that are close to the test case on the call stack than in methods that the test case accesses indirectly through many other methods. Based on this hypothesis, we propose the minimal stack distance between test case and method as a new test measure, which expresses how close any test case comes to a given method, and study its correlation with test effectiveness. We conducted an empirical study with 21 open-source projects, which comprise in total 1.8 million LOC, and show that a correlation exists between stack distance and test effectiveness. The correlation reaches a strength up to 0.58. We further show that a classifier using the minimal stack distance along with additional easily computable measures can predict the mutation testing result of a method with 92.9% precision and 93.4% recall. Hence, such a classifier can be taken into consideration as a light-weight alternative to mutation testing or as a preceding, less costly step to that.Comment: EASE 201

Evaluation and improvement of automated software test suites

Automatisierte Softwaretests sind eine wichtige Qualitätssicherungsmaßnahme in Softwareprojekten und helfen Fehler in einer Anwendung frühzeitig aufzudecken. Zur Bewertung von Testsuiten wurden in der Vergangenheit verschiedene Metriken und Verfahren vorgeschlagen. Dabei sind Code-Coverage-Metriken am weitesten verbreitet und werden vor allem in der kommerziellen Softwareentwicklung eingesetzt. Jedoch sind diese nur bedingt geeignet, die Effektivität von Testsuiten hinsichtlich ihrer Fehleraufdeckungsrate zu bewerten. Ein anderes wirkungsvolles und aussagekräftiges Verfahren ist Mutation Testing, bei dem Fehler in den Anwendungscode einer Software eingefügt werden und geprüft wird, ob die vorhandenen Testfälle diese aufdecken können. In Bezug auf die Bestimmung der Testeffektivität ist Mutation Testing anderen Verfahren deutlich überlegen, jedoch ist es sehr rechenintensiv und sogenannte äquivalente Mutanten können die Ergebnisse verfälschen. Wegen dieser Probleme wird Mutation Testing in der Praxis derzeit kaum eingesetzt. Das Ziel dieser Dissertation ist es, aussagekräftigere Metriken und Verfahren zur Bewertung von Testsuiten zu entwickeln, welche mit vertretbarem Berechnungsaufwand anwendbar sind. Diese sollen Code-Coverage-Metriken in Bezug auf die Aussagekraft übertreffen und gleichzeitig weniger rechenintensiv als derzeit verwendete Mutation-Testing-Verfahren sein. Dazu wurde ein leichtgewichtiges Verfahren zur Erkennung von scheingetesteten Methoden konzipiert, umgesetzt und evaluiert. Scheingetestete Methoden sind von mindestens einem Testfall überdeckt, jedoch erkennt keiner der überdeckenden Testfälle, wenn die gesamte Logik aus der Methode entfernt wird. Außerdem wurde ein Machine-Learning-Modell zur Vorhersage von scheingetesteten Methoden entwickelt, welches ein neu eingeführtes Maß für die Aufrufdistanz zwischen Methoden und Testfällen sowie weitere kostengünstig berechenbare Metriken verwendet. Im Rahmen der Arbeit wurde ein weiteres Machine-Learning-Modell zur Identifizierung von Methoden mit einem niedrigem Fehlerrisiko vorgeschlagen. Solche Methoden können bei Qualitätssicherungsmaßnahmen nachrangig behandelt oder ausgeschlossen werden, sodass beispielsweise der Aufwand für die Erkennung scheingetesteter Methoden weiter reduziert wird. Die Ergebnisse zeigen, dass scheingetestete Methoden in allen untersuchten Studienobjekten auftreten und relevante Testunzulänglichkeiten darstellen. Machine-Learning-Modelle können scheingetestete Methoden effizient vorhersagen, sodass diese Modelle als eine kostengünstige Annäherung vor einer Mutationsanalyse eingesetzt oder in Situationen verwendet werden können, in denen Mutationsanalysen nicht anwendbar sind. Mit einem weiteren Machine-Learning-Modell können basierend auf Code-Metriken Methoden identifiziert werden, die ein niedriges Fehlerrisiko aufweisen. Dies trifft auf etwa ein Drittel der Methoden zu, die folglich im Test mit einer niedrigeren Priorität behandelt werden können. Die entworfenen Verfahren ermöglichen sowohl eine verhältnismäßig leichtgewichtige, anwendbare Berechnung von scheingetesteten Methoden als auch eine Vorhersage derselben basierend auf Methoden- und Testfallmetriken. Durch scheingetestete Methoden aufgedeckte Probleme in Testsuiten sind für Entwickler einfach verständlich und adressierbar, sodass Entwickler die Effektivität ihrer Testsuite verbessern können. Außerdem hilft die Identifikation von Methoden mit einem niedrigen Fehlerrisiko, Testaufwände auf relevante Methoden zu fokussieren. Effektivere Testsuiten können mehr Fehler bereits während des Softwareentwicklungsprozesses aufdecken und helfen damit, die Qualität eines Softwareprodukts zu verbessern sowie Fehlerfolgekosten zu reduzieren

Test.txt

Test

How Much Code Covered By Tests is Pseudo-Tested?

Dataset of the <b>ISSTA 2017 paper by Niedermayr et al.</b><br><br>We analyzed test cases of 19 open-source projects using mutation testing. We determined for each covered method whether at least one test case can detect if the method’s whole logic is removed. We studied method characteristics and relations to test cases to €find indicators for covered methods that are pseudo-tested.<br><br>The SQL dump requires a MySQL database (version >= 5.7).<br

How Many Methods Covered By Tests Are Pseudo-Tested?

Accompanying dataset for the paper <b>"How Many Methods Covered By Tests Are Pseudo-Tested?" (IEEE Transactions on Reliability: Special Section on Software Testing and Program Analysis)</b><br><br>We analyzed test cases of 19 open-source projects using mutation testing. We determined for each covered method whether at least one test case can detect if the method’s whole logic is removed. We studied method characteristics and relations to test cases to €find indicators for covered methods that are pseudo-tested.<br><br>The SQL dump requires a MySQL database (version >= 5.7)